home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000025_news@newsmaster….columbia.edu _Wed Oct 1 20:23:56 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id UAA15160
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 1 Oct 1997 20:23:55 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id UAA29285
  7.     for kermit.misc@watsun; Wed, 1 Oct 1997 20:23:55 -0400 (EDT)
  8. Path: news.columbia.edu!panix!news.eecs.umich.edu!newsxfer3.itd.umich.edu!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit via PPP under DOS?
  12. Message-ID: <XrKuqa+e0PBq@cc.usu.edu>
  13. Date: 1 Oct 97 17:38:37 MDT
  14. References: <k1c7kBQEU5Wv@cc.usu.edu> <omafgv99sa.fsf@tees.cs.ualberta.ca>
  15. Organization: Utah State University
  16. Lines: 80
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:7790
  18.  
  19. In article <omafgv99sa.fsf@tees.cs.ualberta.ca>, Vladimir Alexiev <vladimir@cs.ualberta.ca> writes:
  20. > In article <k1c7kBQEU5Wv@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  21. > 
  22. >>     Let's go through the PPP driver situation again when the driver
  23. >> presents an Ethernet Packet Driver interface.
  24. >>     PPP is a point to point link involving only two stations: this
  25. >> end and the other end. It is not a broadcast medium, and thus ARP does not
  26. >> apply. 
  27. > pppd with the proxyarp option allows this. Here's what the pppd(8) man page
  28. > says: 
  29. >           Add an entry to this system's ARP  [Address  Resolution
  30. >           Protocol] table with the IP address of the peer and the
  31. >           Ethernet address of this system.
  32. > Also, some terminal servers provide such proxy arp. At least the Cisco
  33. > terminal server that runs at our uiniversity's login server. (Interestingly,
  34. > it only does this when the user properly identified themselves to the server,
  35. > otherwise it allows PPP, but does not give proxy arp.)
  36. > 
  37. >>     A PPP driver presenting an Ethernet interface is indistinguishable
  38. >> from real Ethernet at the protocol stack level (i.e., by Kermit). That
  39. >> driver must then FULLY simulate a broadcast medium of many stations, yet
  40. >> they often fail completely to do that job.
  41. > 
  42. > I'm not saying that the Kermit class 1 handling is worse than than of other
  43. > WATTCP apps. I suspect that Kermit does some more checks or expects more from
  44. > the ethernet driver than other WATTCP apps, in other words it uses the
  45. > ethernet driver more properly than other WATTCP apps. But the fact remains
  46. > that these apps can use emulated class 1 drivers, while Kermit can't.
  47. > Sometimes worse is better.
  48.  
  49.     This looks more and more like an argument waiting to happen, due to
  50. lack of specific information. I thought I explained the difficulties with
  51. a driver purporting to be Ethernet but isn't; they are fundamental. The
  52. paragraph above is so loose that I am discarding it.
  53.  
  54. >>  Half measures are failures too.
  55. > 
  56. > Well, these half measures prove to be adequate for other WATTCP apps.
  57.  
  58.     which are tailored for a point to point link, no doubt.
  59.  
  60. >>         SLIP is a point to point link. It is not an Ethernet-style
  61. >> interface. Kermit knows about SLIP and treats it as a point to point
  62. >> comms pathway without MAC addresses. Use SLIP interfaces.
  63. > 
  64. > What are the benefits of an ethernet interface to a SLIP interface:
  65. > - there are apps that only support ethernet interfaces. Kermit couldn't
  66. >   coexist with such apps because it demands a SLIP interface.
  67.  
  68.     Argumentative again. No, Kermit does not "demand" SLIP, but if the
  69. alternatives fail to meet specs then that is hardly Kermit's fault.
  70.  
  71. > - Ethernet interfaces support BOOTP. Is BOOTP impossible with a SLIP
  72. >   interface? 
  73. > - How about DHCP?
  74.  
  75.     Time to read up on these guys. Both use UDP over IP. How IP gets
  76. put onto the wire is another matter. Please do keep in mind that both
  77. BOOTP and DHCP are sensitive to physical address, something which SLIP
  78. lacks.
  79.  
  80. > - RARP is obviously impossible with a SLIP interface, but then it doesn't even
  81. >   apply.
  82. > - Is there anything else?
  83. > 
  84. >> There is no such thing as a standardized PPP interface, alas, and thus
  85. >> Kermit does not have code to deal with the many PPP interfaces out there.
  86. > 
  87. > EtherPPP's documentation mentions class 15 (SLFP). Is that an example of a
  88. > non-standardized PPP interface?
  89. > 
  90. >>     Avoid badly designed PPP drivers, please.
  91. > 
  92. > Since Kermit doesn't work with EtherPPP -k 1, does that make EtherPPP a badly
  93. > designed driver too? How about Windows PPP drivers, do they support an
  94. > Ethernet interface?
  95.  
  96.     I think this ground was well covered in my long message on the 
  97. matter a couple of weeks ago.
  98.     Joe D.